Method, apparatus, and computer-readable medium for format preserving encryption of a numerical value

ABSTRACT

A system, method and computer-readable medium format-preserving encryption of a numerical value, including storing a binary numerical value, the binary numerical value comprising a plurality of binary bits, dividing the plurality of binary bits into a plurality of bit groups and storing the plurality of bit groups in a plurality of bytes, encrypting each byte in the plurality of bytes using a radix value corresponding to a quantity of binary bits in a bit group corresponding to that byte to generate a plurality of ciphertext bytes, and combining a quantity of least-significant bits from each ciphertext byte in the plurality of ciphertext bytes to generate a binary ciphertext value, the quantity of least-significant bits combined from each ciphertext byte corresponding to the radix value used to generate that ciphertext byte.

RELATED APPLICATION DATA

This application is a continuation of U.S. patent application Ser. No.16/542,899 filed Aug. 16, 2019, the disclosure of which is herebyincorporated by reference.

BACKGROUND

Format Preserving Encryption (FPE) is a cryptographic technique thatretains the format of the original plaintext in a derived ciphertext,including the length of the original plaintext and the alphabet used inthe original plaintext. For example, an FPE encrypted character stringrepresenting a credit card number would preserve the original length ofthe credit card and be composed of digits.

FPE can be used to generate realistic ciphertext by encrypting subsetsof characters within a character string according to the alphabetsappearing within the corresponding subsets. For example, if the firstfour digits of a plaintext credit card number include values in the 0-4range, then the first four digits of the ciphertext credit card numbercan also be limited to the 0-4 range.

FPE provides a number of advantages. Ciphertext created using FPE isable to pass validity checks, such as Lunh check digit validation.Additionally, FPE allows for the creation of realistic looking encrypteddata objects which derive their properties from the original plaintextdata objects and thereby safeguard privacy of the original informationby creating the illusion that the ciphertext objects are plaintext dataobjects.

Standard FPE encryption algorithms include two format preservingencryption algorithms, FF1 and FF3, that have been approved by NationalInstitute of Standards and Technology (NIST) for use with the NISTapproved Advanced Encryption Standard (AES) and Triple Data EncryptionAlgorithm (TDEA).

Standard FPE algorithms are based on standard symmetric cryptographicmethods such as the AES block cipher. In addition to a cryptographickey, standard FPE algorithms utilize two initialization vectors called“tweaks.” By changing the tweaks, variability of the ciphertext isachieved for the identical instances of a plaintext. An additionalparameter of a standard FPE algorithm is the “base”—the number ofcharacters in an alphabet which comprise a data object or a part of dataobject. The base is denoted by “radix.” If a data object is comprised ofmore than one logical character set, such as a mix of letters anddigits, each of the logical character sets may be represented by adistinct base.

Standard FPE algorithms are designed for encrypting character data.Numeric data of integral types (e.g., an n-bit integer) may be encryptedin a size preserving manner by applying a n-bit block cipher. Forexample, a 128-bit block cipher is approved for general-purpose use withAES and a 64-bit block cipher is approved for general-purpose use withTDEA.

As discussed above, existing FPE algorithms rely on character levelencryption, even when applied to numerical data. This character levelencryption can create memory overflow problems when encrypting numericaldata. In particular, when the generated ciphertext is converted backinto a numerical representation, the size of the ciphertext number canoften exceed the block of memory that was originally allocated to theplaintext number. For example, a 16-bit integer value can have valuesranging between 0-65535. If an integer having a value of “34212” isencrypted on a character level, the result could exceed the 16 bitsallocated to store the integer, since character level encryption doesnot account for the integer data type. For example, a ciphertext valueof “67535” would require 17 bits to store as an integer.

Given the wide variety of numeric formats and numeric data types, acryptographic standards compliant method and system for encrypting suchdata objects in a data type consistent form is needed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the application of an FPE algorithm to a plaintextcharacter string 100 representing a credit card number

FIG. 2 illustrates the application of standard FPE algorithms to a 16bit integer.

FIG. 3 illustrates a flowchart for format-preserving encryption of anumerical value according to an exemplary embodiment.

FIG. 4 illustrates an example of format-preserving encryption of anumerical value according to an exemplary embodiment.

FIG. 5 illustrates an example of a decryption procedure for decryptingciphertext that is generated using the FPE disclosed herein.

FIG. 6 illustrates an FPE process for encrypting a signed binarynumerical value according to an exemplary embodiment.

FIG. 7 illustrates Institute of Electrical and Electronics Engineers(IEEE) 754 standard floating point numbers.

FIG. 8 illustrates format preserving encryption of a single precisionfloating point value according to an exemplary embodiment.

FIG. 9 illustrates format preserving encryption of a double precisionfloating point data value according to an exemplary embodiment.

FIG. 10 illustrates a flowchart for generating a timestamp binaryciphertext value according to an exemplary embodiment.

FIG. 11 illustrates the process of generating a timestamp binaryciphertext value from an unbounded timestamp according to an exemplaryembodiment.

FIG. 12 illustrates the decimal conversion and normalization process fora timestamp having a lower and upper bound according to an exemplaryembodiment.

FIG. 13 illustrates the process for converting a normalized decimaltimestamp into the binary numerical value according to an exemplaryembodiment.

FIG. 14 illustrates the process of generating a rangebound ciphertexttimestamp for a timestamp having an upper and lower bound according toan exemplary embodiment.

FIG. 15 illustrates a method for encrypting DECIMAL data objects in aformat and data type preserving manner according to an exemplaryembodiment.

FIG. 16 illustrates format and data type preserving encryption of aBoolean data object according to an exemplary embodiment.

FIG. 17 illustrates a specialized computing environment forformat-preserving encryption of a numerical value according to anexemplary embodiment.

DETAILED DESCRIPTION

While methods, apparatuses, and computer-readable media are describedherein by way of examples and embodiments, those skilled in the artrecognize that methods, apparatuses, and computer-readable media forformat-preserving encryption of a numerical value are not limited to theembodiments or drawings described. It should be understood that thedrawings and description are not intended to be limited to theparticular forms disclosed. Rather, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the appended claims. Any headings used herein are fororganizational purposes only and are not meant to limit the scope of thedescription or the claims. As used herein, the word “can” is used in apermissive sense (i.e., meaning having the potential to) rather than themandatory sense (i.e., meaning must). Similarly, the words “include,”“including,” “includes”, “comprise,” “comprises,” and “comprising” meanincluding, but not limited to.

As discussed above, standard format preserving encryption (FPE)algorithms operate on a textual, character-level, basis. FIG. 1illustrates the application of an FPE algorithm to a plaintext characterstring 100 representing a credit card number. Since plaintext characterstring 100 is comprised of digits between 0 and 9, the size of thealphabet which represents credit card numbers is 10, resulting in aradix value 102 of 10. The standard FPE computation also utilizes a16-byte long Advanced Encryption Standard (AES) key 103, a 32-bit longleft tweak 104 and a 32-bit long right tweak 105. The values of the AESkey 103, the left tweak 104, and the right tweak 105 are shown inhexadecimal notation for the purpose of brevity, but it would beunderstood by those skilled in the art that these hexadecimal valuesrepresent underlying binary values. As shown in FIG. 1, the FPEencryption algorithm transforms the plaintext credit card number 100into a cyphertext 101 which belongs to same domain of 16-digit longcharacter strings as the plaintext credit card number 100.

While the approach illustrated in FIG. 1 works well for numeric valuesrepresented by text characters, they are situations where it is notapplicable to binary numeric values. For illustrational purposes onlyand without any limitations we assume that binary values discussed withreference to the figures are presented in the network (“big endian”)byte order.

FIG. 2 illustrates the application of standard FPE algorithms to a 16bit integer 201. The 16 bit integer 201 is represented in alphanumericform 202 prior to application of the FPE algorithm. As shown in FIG. 2,the FPE algorithm is then applied with a Radix value 203 of 10(corresponding to 10 possible characters at each location), an AES Key204, left tweak 205, and right tweak 206.

The result of the FPE algorithm is alphanumeric ciphertext 207. However,as shown in FIG. 2, once the alphanumeric ciphertext 207 is convertedback into a binary representation 208, the number of bits required tostore the value is 17, exceeding the 16 bit integer size.

The problem illustrated by the example in FIG. 2 prevents protection ofdata represented by integer types such as SMALLINT, INTEGER and BIGINTin the databases due to a potential memory overflow of the ciphertextvalue. To overcome loss of data traditional solutions, users must resortto changing the database schema to use larger integer data types such aschanging SMALLINT fields to be INTEGER and INTEGER fields to BIGINT.This approach wastes storage space in order to accommodate potentialoverflow issues resulting from encryption. Additionally, this approachrequires a cumbersome process of creating a new database schema, copyingthe original data to a new location, validating copied data, etc. Thissequence of operations is frequently complex and error prone, and canresult in data loss, data corruption, or both.

Furthermore, within the security context, even if larger ciphertextvalues could be stored, the traditional approach of applying standardFPE to alphanumeric representations of numeric values creates a securityvulnerability. In particular, an attacker is able to discern encrypteddata by noticing that the ciphertext values are outside of the range ofthe original data universe of discourse.

It will be appreciated that the problem illustrated in FIG. 2 affectscryptographic transforms of integral (integer based) data types ingeneral and not only 16 bit integer (“int”) data types. For example,floating point objects, timestamps, and decimal data types also sufferfrom the above-mentioned drawbacks when standard FPE algorithms are usedto perform encryption.

The inventors have discovered a method, apparatus, and computer-readablemedium for performing FPE that overcomes the above-mentioned technicalchallenges and preserves not only the format of plaintext data to beencrypted, but also the data type of the data to be encrypted. Thissolution eliminates the problem of memory overflow and can beimplemented without increasing storage size of data types to accommodatepotential overflow issues caused by encryption. Applicant notes thatseveral of the binary values discussed in this application arerepresented in hexadecimal format for clarity and ease of reference. Itis appreciated that these values would be stored in a binary format inmemory.

FIG. 3 illustrates a flowchart for format-preserving encryption of anumerical value according to an exemplary embodiment.

At step 301 a binary numerical value is stored. The binary numericalvalue can be received from an executing process and/or as part of arequest. For example, binary numerical value can be passed in as anargument in a function call (such as an encryption request). The binarynumerical value can also be stored in a database and passed to anencryption as an argument by reference, meaning a memory location of thestored binary numerical value is passed to the function.

The binary numerical value can be any type of numerical data type thatis represented using a predefined number and/or range of bits within acomputer storage system, such as an “integer” type, a “floating point”(float) type, a “smallint” type, a “decimal” type, a “numeric” type, a“real” type, and/or a “double” type. It is understood that the binarynumerical value can represent any number and is itself not limited tobeing just 0 or 1 (unless it is a Boolean data type). Therefore, the“binary” aspect of the numerical value refers to the bits used to storeall values having the same data type as the binary numerical value.

The binary numerical value comprises a plurality of bits. In the case ofan integer data type as is commonly used in SQL databases, the binarynumerical value can comprise 16 bits. In the case of a float data type,the binary numerical value can comprise 32 bits or 64 bits. Manyvariations are possible and these examples are not intended to belimiting.

FIG. 4 illustrates an example of format-preserving encryption of anumerical value according to an exemplary embodiment. As shown in FIG.4, the stored binary numerical value is integer 401, which isrepresented by 15 bits. In this case, the binary numerical value 401 is111 1010 1110 0001, which corresponds to the decimal value “31457.” Ifthe integer is stored or read in decimal notation then it can beconverted into binary notation.

Returning to FIG. 3, at step 302 the plurality of binary bits in thebinary numerical value are divided into a plurality of bit groups andthe plurality of bit groups are stored in a plurality of bytes. Thisstep begins with the least significant bits of the binary numericalvalue and stores each successive set of 4 bits (referred to herein as a“half-byte” or “nibble”) into the 4 least significant bits of a separatebyte, with the 4 most significant bits of each separate byte being setto 0. One of skill in the art would understand the term “leastsignificant” to refer to the rightmost bit(s) of a binary value and theterm “most significant” to refer to the leftmost bit(s) of a binaryvalue.

This step traverses from the least significant bit to the mostsignificant bit in the binary numerical value, placing 4 bit groupingsinto separate bytes as it encounters them. Any remaining bits in thebinary numerical value that are less than 4 bits long are placed intotheir own separate byte. For example, in the case of a 14 bit integer,there would be 2 remaining bits after the 12 least significant bits havebeen placed into 3 separate bytes. In this case, the 2 remaining bitswould be placed into their own byte, with the remaining most significantbits in that byte (6 bits) being set to 0.

FIG. 4 illustrates the step of dividing the plurality of binary bits inthe binary numerical value 401 into a plurality of bytes 402. As shownin FIG. 4, the 4 least significant bits in binary numerical value 401are placed into byte 402(D), the next 4 least significant bits in binarynumerical value 401 are placed into byte 402(C), the next 4 leastsignificant bits in binary numerical value 401 are placed into byte402(B), and the remaining 3 bits in binary numerical value 401 areplaced into byte 402(A). In the example shown in FIG. 4, there are fourbit groups that are generated by dividing the binary numerical value401. The four bit groups are {0001}, {1110}, {1010}, and {111}, andthese bit groups are stored, respectively, in bytes 402(D), 402(C),402(B), and 402(A).

Returning to FIG. 3, at step 303 each byte in the plurality of bytes isencrypted using a radix value corresponding to a quantity of binary bitsin a bit group corresponding to that byte to generate a plurality ofciphertext bytes. The quantity of binary bits within the bit group thatis stored in (and corresponds to) each byte is used to determine theradix value during encryption because the total number of bits in eachbyte is always 8, and if a radix value of 8 were to be used, theresulting ciphertext byte could exceed the number of bits in theoriginal plaintext bit group that was added to the byte. Specifically,the radix value used to encrypt a byte can be determined as the maximumnumber of possible values representable by the quantity of binary bitsin a bit group corresponding to that byte.

So, for example, if the bit group “011” was stored in its own byte instep 302, then that byte would be encrypted using radix 8, since thereare eight possible values of three bits. Similarly, if the bit group“11” was stored in its own byte in step 302, then that byte would beencrypted using radix 4, since there are four possible values of twobits. In another example, if the bit group “0000” was stored in its ownbyte in step 302, then that byte would be encrypted using radix 16,since there are sixteen possible values of four bits.

During the encryption step 303, each byte in the plurality of bytes canbe individually encrypted with a format preserving encryption algorithmusing an encryption key K and left and right tweaks (TL and TR), withthe radix value for each byte being determined as discussed above.

The encryption step 403 of each byte is shown in FIG. 4. As shown inthat figure, bytes 402(B), 402(C), 402(D) are all encrypted using Radix16 403(B) because the bit groups corresponding to those bytes all have 4bits (“1010,” “1110,” and “0001” respectively). Additionally, byte402(A) is encrypted using Radix 8 403(A) because that byte has 3 bits inthe corresponding bit group (“111”) added to that byte in the previousdividing and storing step. The use of a radix value corresponding to thequantity of bits in each bit group stored in each byte ensures that theresulting ciphertext bytes stay within the universe of discourse of theplaintext bytes and that the ultimate ciphertext value stays within theuniverse of discourse of the original plaintext value. Of course, theencryption step 403 will also utilize an encryption key 403(C) and leftand right tweaks (not shown), as discussed earlier.

The result of the encryption step (403) is a plurality of ciphertextbytes (404), including ciphertext byte 404(A) corresponding to byte402(A), ciphertext byte 404(B) corresponding to byte 402(B), ciphertextbyte 404(C) corresponding to byte 402(C), and ciphertext byte 404(D)corresponding to byte 402(D).

Returning to FIG. 3, at step 304 a quantity of least-significant bitsfrom each ciphertext byte in the plurality of ciphertext bytes arecombined to generate a binary ciphertext value. The quantity ofleast-significant bits combined from each ciphertext byte corresponds tothe radix value used to generate that ciphertext byte. This ensures thatonly the bits that encompass the universe of discourse for a particularradix value will be combined. For example, if a radix value of 16 wasused to generate all ciphertext bytes, then the least significant 4 bitswill be selected from each ciphertext byte. If a radix value of 8 wasused to generate a particular ciphertext byte, then the leastsignificant 3 bits bill be selected from that ciphertext byte.

This combination step is also shown in FIG. 4. Specifically, the leastsignificant 3 bits from ciphertext byte 404(A) and the least significant4 bits from each of ciphertext bytes 404(B), 404(C), and 404(D) arecombined to generate the binary ciphertext value 405. As discussedabove, this is because radix 8 was used in the encryption step togenerate ciphertext byte 404(A) and radix 16 was used in the encryptionstep to generate ciphertext bytes 404(B), 404(C), and 404(D).

In this case, the binary ciphertext value 405 of “110 0100 1100 1010”corresponds to a ciphertext decimal value of “25802.” As shown in FIGS.3-4, the disclosed system and method for performing FPE ensures thatciphertext values stay within the universe of discourse of the originalplaintext values and do not exceed the memory size allocated toparticular data types. The use of an integer with 15 bits in FIG. 4 isexemplary only, and it is understood that the disclosed techniques canbe utilized to encrypt in a data type preserving manner for any numberof binary values with any number bits.

It is appreciated that the format preserving encryption of a binarynumerical value described herein may be implemented in a differentmanner such as, but not limited to, mapping each bit of the binarynumerical value to a different byte and encrypting each byte in in radix2. Similarly, other divisions of the bits of the binary numerical valueinto bytes can be used such that format preserving encryption isperformed in radix 4, 8 or a mixture of thereof.

FIG. 5 illustrates an example of a decryption procedure for decryptingciphertext that is generated using the FPE disclosed herein. As shown inFIG. 5, binary ciphertext value 501 is stored that comprises a pluralityof binary ciphertext bits. In this example, the binary ciphertext valuehas 16 ciphertext bits.

The plurality of binary ciphertext bits are divided into a plurality ofciphertext bit groups and stored in a plurality of ciphertext bytes 502.In the example shown in FIG. 5, ciphertext bit group “0110” is stored inciphertext byte 502(A), ciphertext bit group “0100” is stored inciphertext byte 502(B), ciphertext bit group “1100” is stored inciphertext byte 502(C), and ciphertext bit group “1010” is stored inciphertext byte 502(D). Similar to the encryption process, eachciphertext bit group is stored at the least significant position of theciphertext byte and the more significant bits of each ciphertext byteare set to zeroes.

Each byte in the plurality of ciphertext bytes 502 is then decryptedusing a radix value corresponding to a quantity of binary ciphertextbits in a ciphertext bit group corresponding to that ciphertext byte,decryption key 503(C), and left and right tweaks (not shown) to generateplaintext bytes 504. For example, since ciphertext byte 502(A) includesonly 3 binary ciphertext bits in the corresponding ciphertext bit group(“110”), it is decrypted using radix 8 503(A) to generate plaintext byte504(A). The remaining ciphertext bytes 502(B), 502(C), and 502(D) allhave 4 binary ciphertext bits in their corresponding ciphertext bitgroups (“0100,” “1100,” and “1010” respectively), so they are alldecrypted using radix 16 503(B) to generate plaintext bytes 504(B),504(C), and 504(D).

As shown in FIG. 4, a quantity of least-significant bits from eachplaintext byte in the plurality of plaintext bytes 504 are combined togenerate a binary plaintext value 505. The quantity of least-significantbits combined from each plaintext byte corresponds to the radix valueused to generate that plaintext byte. For example, radix 8 decryptionwas used to generate plaintext byte 504(A) so the three leastsignificant bits in that plaintext byte are used to generate the binaryplaintext value 505. Once again, this ensures that the appropriatedecrypted value within the universe of discourse for the numerical valuedata type is generated during the decryption process.

The disclosed techniques for encrypting bit sequences in a formatpreserving fashion also enables sign preservation of the resultingciphertext. Returning to FIG. 3, when the binary numerical value is asigned value (such as a signed integer), then at step 305 the sign bitof the binary numerical value is stored in the leftmost bit of a signbyte. After steps 302-304 are performed, the leftmost bit of the signbyte is then combined with the binary ciphertext value at step 306 togenerate a signed binary ciphertext value. This step can be performed,for example, by propagating the sign bit from the leftmost position inthe sign byte to the leftmost position in the binary ciphertext value.

FIG. 6 illustrates an FPE process for encrypting a signed binarynumerical value according to an exemplary embodiment. For illustrationpurposes and without any limitation we assume that signed binary valuesfollow the two's complement representation and use a 16-bit signed valuein the example shown in FIG. 6.

Further referring to FIG. 6, signed 16-bit integer 601 is a signed valuein which the leftmost bit 601(A) is the sign bit representing the signand the remaining bits 601(B) are the plurality of binary bits asdiscussed above. The sign value is positive when the leftmost bit is setto 0 and negative if the leftmost bit is set to 1. In this example the16-bit signed integer is the value “1111 1010 1101 0001.”

As shown in FIG. 6, to perform format preserving encryption with signpreservation, the plurality of binary bits 601(B) are divided into aplurality of bit groups and stored in bytes 602(B). For ease ofreference and clarity, the bits in each byte are represented in thefigure in hexadecimal notation. For example, the first byte (0x7)represents the binary value “111” and corresponds to the 3 mostsignificant bits of the plurality of binary bits 601(B). The remainingbytes all correspond to other 4 bit groups within the plurality ofbinary bits 601(B).

Additionally, the sign bit 601(A) is stored in the leftmost bit of asign byte 602(A). Again, the bits of the sign byte are shown inhexadecimal notation, but it is understood that the hexadecimal value“0x80” corresponds to the binary value “1000 0000.” Together, the signbyte 602(A) and the plurality of bytes 602(B) form all of the bytes 602used to store values extracted from the signed numerical value 601.

Each of the plurality of bytes 602(B) are then encrypted 603 asdiscussed with reference to previous figures, with byte 0x07 beingencrypted using radix 8 603(A) encryption and the remaining bytes beingencrypted using radix 16 603(B) encryption. This results in a pluralityof ciphertext bytes 604 including bytes 604(B) and the sign byte 602(A)which is not encrypted and is unchanged. The storage of the sign bit inthe left-most half-byte of each of the bytes 602 can be used to signalto the encryption process 603 not to perform encryption on the signbyte.

As shown in FIG. 6, a quantity of least-significant bits is combinedfrom each of the ciphertext bytes 604(B) to generate a binary ciphertextvalue. As discussed previously, the quantity of least-significant bitscombined from each ciphertext byte corresponds to the radix value usedto generate that ciphertext byte.

Additionally, the leftmost (most significant) bit of the sign byte iscombined with the binary ciphertext value to generate signed binaryciphertext value 605. In particular, the leftmost bit of the sign byteis appended onto the binary ciphertext value to generate the signedbinary ciphertext value 605.

As discussed earlier, the FPE process described herein can be applied toany data type and preservers the data type of the binary numerical valueto which it is applied. The binary numerical value can be, for example,a floating point value including a sign bit and a plurality of binarybits and in which the plurality of binary bits include a plurality ofexponent bits and a plurality of mantissa bits.

FIG. 7 illustrates Institute of Electrical and Electronics Engineers(IEEE) 754 standard floating point numbers. A number in IEEE 754single-precision 32-bit floating point format 700 consists of 23 bitsrepresenting the mantissa 704, 8 bits representing the exponent 703 andone sign bit 702. A special combination of exponent 703 bits, “11111111”, identifies a floating-point object NaN (“not a number”). Aninfinite floating-point value is represented by setting all mantissa 704bits to 0.

Further referring to FIG. 7, a number in IEEE 754 double-precision64-bit floating point format 701 consists of 52 bits representing themantissa 707, 11 bits representing the exponent 706 and one sign bit705. A special combination of exponent 706 bits, “111 1111 1111”,identifies a floating-point object NaN (“not a number”). An infinitefloating-point value is represented by setting all mantissa 707 bits to0.

FIG. 8 illustrates format preserving encryption of a single precisionfloating point value according to an exemplary embodiment. The floatingpoint value is shown in decimal plaintext 801 (“3.14159”) and thecorresponding binary numerical value 802. If the floating point value isstored or read in decimal notation then it can be converted into binarynotation. The binary numerical value a sign bit (the first bit), 8 bitsof the exponent 802A and 23 bits of the mantissa 802B.

The binary numerical value 802 is converted into a plurality of bytes803 using the processes described above. In this case, the bytes 803include a sign byte (the first byte), two bytes 803A corresponding tothe eight-bit exponent 802A, and six bytes 803B corresponding to the 23bit mantissa 802B. Of the mantissa bytes 803B, the leftmost 3 bits ofthe mantissa 802B are stored in the leftmost byte and each of theremaining 20 bits of the mantissa 802B are stored in five groups of fourbits each.

Further referring to FIG. 8, the encryption step transforms theplurality of bytes 803 into a plurality of ciphertext bytes 804 byencrypting each byte in the plurality of bytes 803, using the encryptionprocess described with reference to the previous figures and explainedin greater detail below.

The leftmost byte (“0x00”) in the plurality of bytes 803 corresponds tothe sign byte and is encrypted in radix 2. Of course, if signpreservation is desired, then the sign bit can be stored in the mostsignificant (leftmost) position in the sign byte and the encryption stepcan be omitted for the sign byte. The following two bytes 803A (“0x080x01”) in the plurality of bytes 803 are encrypted in radix 16. The nextbyte (“0x04”) is encrypted in radix 8 because it only corresponds to 3bits of the mantissa. The remaining five mantissa bytes (“0x09 0x00 0x0f0x0d 0x00”) and are encrypted in radix 16.

Further referring to FIG. 8, a quantity of least significant bits fromthe ciphertext bytes 804 are then combined to generate a signed binaryciphertext 805. The signed binary ciphertext 805 includes the rightmostbit of the ciphertext sign byte (“0x1”), the rightmost half-bytes of thefollowing two cipher text bytes (“0xa, 0x1”), the three rightmost bits(“0x7”) of the next ciphertext byte and the rightmost half-bytes of theremaining five bytes (“0x1 0x1 0xb 0x6 0x4”). As shown in FIG. 8, thesigned binary ciphertext 805 corresponding to a ciphertext floatingpoint value 806 can be represented or converted into decimal format 806(“−3.2360833024E10”).

FIG. 9 illustrates format preserving encryption of a double precisionfloating point data value according to an exemplary embodiment. Theprocess shown in FIG. 9 is similar to that shown in FIG. 8 and in thepreceding figures and description. The floating point value is shown indecimal notation 901. If the floating point value is stored or read indecimal notation then it can be converted into binary notation. Thecorresponding binary numerical value 902 includes bits corresponding tothe sign (leftmost bit), the exponent 902A, and the mantissa 902B. Thesebits are then divided into bit groups and places into bytes 903,including bytes corresponding to the sign (leftmost byte), bytescorresponding to the exponent 903A, and bytes corresponding to themantissa 903B. In this case, the sign byte corresponds to a single signbit, the leftmost exponent byte (“0x04”) corresponds to the threeleftmost bits of exponent 902A and the remaining bytes all correspond to4 bits. The bytes 903 are then encrypted to generate ciphertext bytes904. A quantity of bits from each binary ciphertext byte (correspondingto the radix value used for encryption) are then combined to generatebinary ciphertext byte 905, corresponding to the ciphertext floatingpoint value shown in decimal notation 906.

The decryption process for decrypting a floating point value is areverse process that that shown in FIGS. 8-9, in which a ciphertextfloating point value is the input and the output is a plaintext floatingpoint value. The decryption process will follow the reverse order ofsteps shown in FIGS. 8-9.

Another type of binary numerical value that can be encrypted using theFPE described herein is a numerical timestamp. The numerical timestampcan be represented by, for example, UNIX time. UNIX time is a 32-bit ora 64-bit signed binary value representing time elapsed since 00:00:00Coordinated Universal Time (UTC) of Jan. 1, 1970.

FIG. 10 illustrates a flowchart for generating a timestamp binaryciphertext value according to an exemplary embodiment. As will bediscussed below, the steps shown in FIG. 10 cover the scenario where thetimestamp is encrypted without any bounds (steps 1001-1002, 1006-1007,and 1009) and the scenario where the timestamp is encrypted subject toupper and/or lower bounds (steps 1001-1009). Each of these scenarios arediscussed separately below.

At step 1001 a timestamp is received. The timestamp can be received froman executing process and/or as part of a request. For example, thetimestamp can be passed in as an argument in a function call (such as anencryption request). The timestamp can also be stored in a database andpassed to an encryption as an argument by reference, meaning a memorylocation of the stored timestamp is passed to the function. Thetimestamp can also be read from a portion of the memory storing thecurrent system time.

At step 1002 the timestamp is converted into a decimal timestamp. If theUNIX time convention is used, this can be performed by computing thenumber of seconds elapsed since the Coordinated Universal Time (UTC) ofJan. 1, 1970 based on the timestamp.

At step 1006 the decimal timestamp can then be converted into a binarynumerical value including a flag half-byte with a flag bit and aplurality of binary bits. This can be performed by changing from decimalnotation to binary notation. As will be illustrated in the followingfigures, for UNIX time, the flag bit is a leftmost non-zero bit to theright of the sign bit of the UNIX time value.

At step 1007 a determination can be made regarding whether upper andlower bounds have been received or determined. Optionally, this step canbe omitted and separate process flows can be implemented for a timestamphaving upper and lower bounds and timestamp without bounds.

When there are no upper and lower bounds, at step 1009 a ciphertexttimestamp value is generated. This step is performed by first storingthe flag bit in a flag byte and storing any remaining bits lesssignificant than the flag bit within the flag half-byte in a remainderbyte. The remainder byte is then encrypted using a radix valuecorresponding to a quantity of remaining bits within the remainder byteto generate a ciphertext remainder byte. A binary OR operation is thenapplied to the flag byte and the ciphertext remainder byte to generate aresult flag half-byte. The result flag half-byte is then combined withthe binary ciphertext value generated from the plurality of binary bits(using the techniques described in FIGS. 3-4) to generate a timestampbinary ciphertext value. This timestamp binary ciphertext value is thenconverted into a ciphertext decimal value and subsequently into aciphertext timestamp

FIG. 11 illustrates the process of generating a timestamp binaryciphertext value from an unbounded timestamp according to an exemplaryembodiment. Timestamp 1101 is converted into decimal timestamp 1102.This is performed by converting the timestamp into a total number ofseconds elapsed since UTC. This can include, for example, determiningthe total number of days between the date indicated by the timestamp(2000-04-01) and UTC (1970-01-01), multiplying that value by 24 hours ina day, multiplying that value by 60 minutes in an hour, and multiplyingthat value by 60 seconds in a minute.

The decimal timestamp 1102 is then converted into binary numerical value1103. The binary numerical value 1103 includes a flag half-byte 1103A(“0011”) which includes both the sign bit and the flag bit. The sign bitis the leftmost bit value (“0”) and the flag bit is the leftmostnon-zero bit to the right of the sign bit of the UNIX time value (thefirst “1” in the flag half byte 1103A). The binary numerical value 1103also includes a plurality of binary bits 1103B after the flag half-byte.

The binary numerical value 1103 is then separated into bytes 1104. Theflag bit (“1”) is stored in flag byte 1104A. Applicant notes that flagbyte 1104 has the value 0x02 because the flag bit “1” is located at the2's position within flag half-byte 1103A. The only remaining bit withinflag half-byte 1103A after the flag bit is therefore another “1” bit.This remaining “1” bit is stored in a remainder byte 1004B. Remainderbyte 1004 has the value 0x01 because the remaining bit is located at the1's position within flag half-byte. The plurality of binary bits 1103Bare stored in bytes 1104C as described with respect to FIGS. 3-4.

All of the bytes 1104 other than the flag byte 1104A are then encryptedto generate ciphertext bytes 1105. Bytes 1104C corresponding to theplurality of binary bits 1103B are encrypted using the techniquesdescribed with respect to FIGS. 3-4 to generate ciphertext bytes 1105C.

The remainder byte 1104B is encrypted using a radix value correspondingto a quantity of remaining bits within the remainder byte to generate aciphertext remainder byte 1105B. In this case, there was only one“remaining bit” added to the remainder byte 1104B, so it is encryptedwith radix 2 to generate ciphertext remainder byte 1105B.

Timestamp binary ciphertext 1106 is generated by first combining aquantity of least significant bits from ciphertext bytes 1105C (thebytes after the flag byte 1104A and the remainder byte 1105B) in themanner described with respect to FIGS. 3-4 (where the quantity for eachbyte is based upon the radix value used to generate that ciphertextbyte) to generate the binary ciphertext value 1106B.

A binary OR operation is then applied to the flag byte 1104A and theciphertext remainder byte 1105B to generate a result flag half-byte1106A. The result flag half-byte 1106A is then combined with the binaryciphertext value 1106B to generate the timestamp binary ciphertext value1106.

The timestamp binary ciphertext 1106 can then be converted back into aciphertext decimal value 1107 and then into a ciphertext timestamp 1108using the conversion process described above.

The decryption process for decrypting a timestamp is a reverse processthat that shown in FIGS. 10-11, in which a ciphertext timestamp is theinput and the output is a plaintext timestamp. The decryption processwill follow the reverse order of steps shown in FIGS. 10-11.

In certain use cases it is important that the encrypted timestamp valueis bound within a certain interval, for example encrypting a UNIX timevalue in a format preserving fashion that guarantees encrypted value tobe bound in a certain range t_(start)<t<t_(end). There are manyscenarios when such bounds are necessary. For example, if a UNIX timevalue represents a date of birth an encrypted UNIX time value containingtime in a future may break an existing application which performs asanity check on the input data. In another example, consider anexemplary time Nov. 17, 1982 at midnight which should be encrypted in arange between the midnight of Apr. 1, 1980 and the midnight of Apr. 1,2000.

Referring to FIG. 10, steps 1001-1009 cover the scenario in which alower-bound and/or upper bound time are utilized when encrypting atimestamp. Steps 1001-1002 are the same regardless of whether an upperand lower bound are received or if there are no bounds.

At step 1003 a lower-bound time and an upper-bound time are received ordetermined. The lower-bound time and upper-bound time can be received aspart of a function call or other process or determined automatically.For example, the upper-bound and lower-bound can be determined basedupon contextual information or metadata (such as what specific value thetimestamp is measuring).

At step 1004 the lower-bound time and the upper-bound time are alsoconverted into a decimal lower-bound and a decimal upper-bound. Thisstep can be similar to the conversion process of step 1002 when thelower-bound and the upper-bound timestamps use the same format.

At step 1005 the decimal timestamp, the decimal upper-bound, and thedecimal lower-bound prior are normalized prior to converting the decimaltimestamp into the binary numerical value in step 1006. Thisnormalization process sets the decimal lower-bound equal to a value ofzero and adjusts the decimal timestamp and the decimal upper-bound tomaintain the same value relative to the normalized decimal lower-bound.For example, if the decimal upper bound was 130, the decimal timestampwas 56, and the decimal lower-bound was 32, then the normalized decimallower-bound be set to zero, the normalized decimal timestamp would 24,and the normalized decimal upper-bound would be 98.

FIG. 12 illustrates the decimal conversion and normalization process fora timestamp having a lower and upper bound according to an exemplaryembodiment. As shown in FIG. 12, an upper-bound timestamp 1201A, atimestamp 1201B, and a lower-bound timestamp 1201C are all received.These are then converted to decimal upper-bound timestamp 1202A, decimaltimestamp 1202B, and decimal lower-bound timestamp 1202C. Decimallower-bound timestamp 1202C is converted to a normalized decimallower-bound 1203C by setting it to zero. Decimal upper-bound timestamp1202A, decimal timestamp 1202B are converted to normalized decimalupper-bound 1203A and normalized decimal timestamp 1203B, respectively,by subtracting the value of the decimal lower-bound timestamp 1202C.

Returning to FIG. 10, at step 1006 the decimal timestamp is convertedinto the binary numerical value, which includes a flag half-bytecomprising a flag bit and a plurality of binary bits. The implementationof step 1006 will differ depending on whether the timestamp has anassociated upper and lower bound or is unbounded. In the case of anormalized decimal timestamp with a normalized upper-bound, thenormalized decimal upper-bound and the normalized decimal timestamp arefirst converted into a binary upper-bound and a binary timestamp.

The binary upper-bound and the binary timestamp are then compared toidentify an initial instance of a half-byte in the binary timestamp thatdiffers from a corresponding half-byte in the binary upper-bound. Aleftmost bit is then identified within the identified half-byte of thebinary timestamp that has a value of 0 where a corresponding bit in thecorresponding half-byte in the binary upper-bound has a value of 1. Forexample, if the identified half-byte in the binary timestamp is “1011”and the corresponding half-byte in the binary upper-bound is “0101,”then the identified bit would be the second bit of the identifiedhalf-byte of the binary timestamp.

This identified bit is then designated as the flag bit, the identifiedhalf-byte is designated as the flag half-byte, and remaining bits in thebinary timestamp are designated as the plurality of binary bits. Theflag bit indicates a position in the binary timestamp that serves as aprocedural boundary. The bits following this procedural boundary aresubject to encryption.

FIG. 13 illustrates the process for converting a normalized decimaltimestamp into the binary numerical value according to an exemplaryembodiment. As shown in FIG. 13, binary upper bound 1302A corresponds tonormalized decimal upper-bound 1301A and binary timestamp 1302Bcorresponds to normalized decimal timestamp 1301B.

The binary upper-bound 1302A and the binary timestamp 1302B are thencompared to identify an initial instance of a half-byte in the binarytimestamp 1302B that differs from the binary upper-bound 1302A. Thishalf-byte is designated as the flag half-byte 1304. Additionally, theflag half-byte 1304 is analyzed to identify a leftmost bit that has avalue of 0 where a corresponding bit in the binary upper-bound is 1.Dashed line 1303 shows the result of this comparison, identifying thethird bit in flag half-byte 1304. This bit is designated as the flag bit1304A. Additionally, the remaining bits in binary timestamp after theflag half-byte are designated the plurality of binary bits 1305.

At step 1007 a determination can be made regarding whether upper andlower bounds have been received or determined. Optionally, this step canbe omitted and separate process flows can be implemented for a timestamphaving upper and lower bounds and timestamp without bounds.

When upper and lower bounds have been received or determined, then atstep 1008 a range-bound ciphertext timestamp is generated. This stepfirst stores any remaining bits less significant than the flag bitwithin the flag half-byte in a remainder byte. For example, if the flaghalf-byte is “1011” and the flag bit is the 0, then the remaining bitsto the right of the 0(“11”) would be stored in a remainder byte.

The remainder byte is then encrypted using a radix value correspondingto a quantity of remaining bits within the remainder byte to generate aciphertext remainder byte. In the above example, two remaining bits arestored in the remainder byte so the remainder byte would be encryptedwith radix 4.

A quantity of least-significant bits in the ciphertext remainder bytecorresponding to the radix value used to generate the ciphertextremainder byte are then combined with the binary ciphertext valuegenerated from the plurality of binary bits (using the techniquesdescribed in FIGS. 3-4) to generate a timestamp binary ciphertext value.

The timestamp binary ciphertext value is then converted into a timestampciphertext decimal value by converting between base-10 (decimal) tobase-2(binary).

A range-bound timestamp ciphertext decimal value is then generated bysubtracting the ciphertext decimal value from the decimal upper-bound.

The range-bound timestamp ciphertext decimal value is then convertedinto a rangebound ciphertext timestamp using the processes describedpreviously for converting between decimal values and timestamps (asmeasured in units of time, such as seconds for UNIX time).

FIG. 14 illustrates the process of generating a rangebound ciphertexttimestamp for a timestamp having an upper and lower bound according toan exemplary embodiment. The original timestamp, upper-bound, andlower-bound are based the examples shown in FIGS. 12-13.

Binary numerical value 1401 is the binary representation of a normalizeddecimal timestamp, which itself is generated from the timestamp, thelower-bound time, and the upper-bound time as discussed above. Thebinary numerical value 1401 includes a flag half-byte 1401A, in whichthe flag bit is the third bit from the left and the remainder bit is thelast bit in the half-byte 1401A.

The binary numerical value 1401 is divided into bytes 1402 using theprocesses described above, with the remainder bit being stored in itsown remainder byte 1402A. These bytes are then encrypted using theappropriate radix values to generate ciphertext bytes 1403.

A quantity of bits from each ciphertext byte (the quantity correspondingto the radix value used during encryption) are then combined to generatetimestamp binary ciphertext 1404.

The timestamp binary ciphertext 1404 is then converted into a ciphertextdecimal value 1405B and substracted from decimal upper-bound 1405A togenerate the range-bound timestamp ciphertext decimal value 1405C.

The range-bound timestamp ciphertext decimal value 1405C is thenconverted into a rangebound ciphertext timestamp 1406 based upon the UTCand a conversion from seconds into a specific date.

Decryption of the encrypted bounded timestamp is a reverse process tothat illustrated in FIGS. 10-14 that takes a rangebound ciphertexttimestamp as input and outputs a rangebound plaintext timestamp. Duringdecryption the range-bound timestamp ciphertext decimal value isnormalized and then subtracted from the decimal upper-bound value. In anext step a flag bit is discovered, a timestamp binary ciphertext valueis constructed, divided into ciphertext bytes, and these are thendecrypted. The plaintext of the rangebound ciphertext timestamp isrecovered by subtracting the decrypted decimal plaintext timestamp fromthe decimal upper-bound value.

With respect to FIGS. 10-14, it is appreciated that the sign bit of UNIXtime values can also be encrypted in a format preserving manner usingradix 2 and the result of encryption can be merged back into binaryciphertext, as discussed with respect to FIG. 6.

Additionally, it is appreciated that the method of encrypting UNIX timevalues disclosed herein may be applied to encrypting in a formatpreserving manner other time counters such as milliseconds counters,microseconds counters, etc.

Another type of numeric data object commonly present in databases is theDECIMAL (p, s) data type which is also called NUMERIC (p, s). Objects ofthis data type are defined as an exact numerical with precision “p” andscale “s.” DECIMAL values are stored in a fixed number of bytes. Thesize of storage is derived from the precision parameter of the DECIMALdata object. Fixed size of storage for DECIMAL values implies thatformat preserving encryption of the DECIMAL data objects requirespreservation of the precision and scale parameters of the plaintext inthe ciphertext. Optionally, sign of the plaintext value may be preservedas well.

FIG. 15 illustrates a method for encrypting DECIMAL data objects in aformat and data type preserving manner according to an exemplaryembodiment. In a first step decimal plaintext 1500 representing DECIMAL(5.2) value “−427.31” is extracted as an alphanumeric value “427.31”1505 and a sign artifact 1507 which takes value 0 if the DECIMAL ispositive and takes value 1 when the DECIMAL is negative. In the nextstep alphanumeric value is transformed into alphanumeric plaintext 1501“42731” by removing the decimal dot (“.”) in alphanumeric value 1505.

In the next step alphanumeric plaintext 1501 “42731” is encrypted in aformat preserving manner using radix 10 1504 and sign artifact 1507 isalso encrypted in format preserving manner using radix 2 1509. This stepproduces alphanumeric ciphertext 1502 “19075” and encrypted signartifact 1508.

In the following step a decimal dot (“.”) character is introduced in aplace specified by the DECIMAL data object format forming encryptedalphanumeric value 1506. In case if the encrypted sign artifact 1508 is1 then encrypted alphanumeric value 1506 is multiplied by −1 making it anegative number. In case if the encrypted sign artifact 1508 is 0 nofurther transformation is applied to the encrypted alphanumeric value1506. In the final step alphanumeric value 1506 is placed in the DECIMALdata object thus creating DECIMAL ciphertext 1503.

Format preserving decryption of a DECIMAL data object is performed inthe reverse order as that shown in FIG. 15.

Another type of data object is the Boolean data object. A Boolean dataobject takes only two values: TRUE and FALSE. As a convention theBoolean value TRUE is associated with a numeric value “1” and Booleanvalue FALSE with a numeric value “0.”

FIG. 16 illustrates format and data type preserving encryption of aBoolean data object according to an exemplary embodiment. In a firststep Boolean plaintext value 1600 representing Boolean value TRUE istranslated into numeric plaintext value 1601 “1” 1605. In a subsequentstep numeric plaintext value 1601 “1” is encrypted in a formatpreserving fashion using radix 2 1604 which results in a numericciphertext value 1606 “1.” In the final step of computation numericciphertext value 1606 “1” is translated into a Boolean ciphertext value1606 TRUE.

The decryption process of a Boolean data object is the reverse of theencryption process shown in FIG. 16.

FIG. 17 illustrates a specialized computing environment forformat-preserving encryption of a numerical value according to anexemplary embodiment. Computing environment 1700 includes a memory 1701that is a non-transitory computer-readable medium and can be volatilememory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM,EEPROM, flash memory, etc.), or some combination of the two.

As shown in FIG. 17, memory 1701 stores binary numerical valueencryption/decryption software 1701A, timestamp processing software1701B, floating point value processing software 1701C, sign bitprocessing software 1701D, bounded timestamp processing software 1701E,decimal encryption/decryption software 1701F, and Boolean data typeencryption/decryption software 1701G. The software stores specializedinstructions and data structures configured to perform the format anddata-type preserving encryption techniques described herein.

Memory 1701 additionally includes a storage that can be used to storeencrypted or decrypted values, intermediate values required forencryption or decryption (such as decimal timestamp values), andencryption and/or decryption keys.

All of the software stored within memory 1701 can be stored as acomputer-readable instructions, that when executed by one or moreprocessors 1702, cause the processors to perform the functionalitydescribed with respect to FIGS. 3-16.

Processor(s) 1702 execute computer-executable instructions and can be areal or virtual processors. In a multi-processing system, multipleprocessors or multicore processors can be used to executecomputer-executable instructions to increase processing power and/or toexecute certain software in parallel.

The computing environment additionally includes a communicationinterface 503, such as a network interface, which is used to monitornetwork communications, communicate with devices, applications, orprocesses on a computer network or computing system, collect data fromdevices on the network, and implement encryption/decryption actions onnetwork communications within the computer network or on data stored indatabases of the computer network. The communication interface conveysinformation such as computer-executable instructions, audio or videoinformation, or other data in a modulated data signal. A modulated datasignal is a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in the signal. By wayof example, and not limitation, communication media include wired orwireless techniques implemented with an electrical, optical, RF,infrared, acoustic, or other carrier.

Computing environment 1700 further includes input and output interfaces1704 that allow users (such as system administrators) to provide inputto the system and display or otherwise transmit information for displayto users. For example, the input/output interface 1704 can be used toconfigure encryption/decryption rules and settings, and perform lookupsof system information (such as UNIX time) used in the above-describedprocesses.

An interconnection mechanism (shown as a solid line in FIG. 17), such asa bus, controller, or network interconnects the components of thecomputing environment 1700.

Input and output interfaces 1704 can be coupled to input and outputdevices. The input device(s) can be a touch input device such as akeyboard, mouse, pen, trackball, touch screen, or game controller, avoice input device, a scanning device, a digital camera, remote control,or another device that provides input to the computing environment. Theoutput device(s) can be a display, television, monitor, printer,speaker, or another device that provides output from the computingenvironment 1700. Displays can include a graphical user interface (GUI)that presents options to users such as system administrators forconfiguring encryption and decryption processes.

The computing environment 1700 can additionally utilize a removable ornon-removable storage, such as magnetic disks, magnetic tapes orcassettes, CD-ROMs, CD-RWs, DVDs, USB drives, or any other medium whichcan be used to store information and which can be accessed within thecomputing environment 1700.

The computing environment 1700 can be a set-top box, personal computer,a client device, a database or databases, or one or more servers, forexample a farm of networked servers, a clustered server environment, ora cloud network of computing devices and/or distributed databases.

Having described and illustrated the principles of our invention withreference to the described embodiment, it will be recognized that thedescribed embodiment can be modified in arrangement and detail withoutdeparting from such principles. Elements of the described embodimentshown in software can be implemented in hardware and vice versa.

In view of the many possible embodiments to which the principles of ourinvention can be applied, we claim as our invention all such embodimentsas can come within the scope and spirit of the following claims andequivalents thereto.

We claim:
 1. A method executed by one or more computing devices forformat-preserving encryption of a numerical value, the methodcomprising: storing a binary numerical value, the binary numerical valuecomprising a plurality of binary bits; dividing the plurality of binarybits into a plurality of bit groups and storing the plurality of bitgroups in a plurality of bytes; encrypting each byte in the plurality ofbytes using a radix value corresponding to a quantity of binary bits ina bit group corresponding to that byte to generate a plurality ofciphertext bytes; and combining a quantity of least-significant bitsfrom each ciphertext byte in the plurality of ciphertext bytes togenerate a binary ciphertext value, wherein the quantity ofleast-significant bits combined from each ciphertext byte corresponds tothe radix value used to generate that ciphertext byte.